REMARKS 

Claims 1-12, 14-23, 25-27, and 29-31 are pending after this amendment. 

Applicants have amended claims 1, 3, 7, 9-11, 14, 16, 18, 19, 21-23, 25-27, and 
29 in order to more particularly define the invention. The amendments were not ne- 
cessitated by the claim rejections. Applicants make no admission as to the pat- 
entability or unpatentability of the originally filed claims. 

Claims 30 and 31 have been added in order to more particularly define the in- 
vention. No new matter has been added. 

Claims 13, 24, and 28 have been cancelled. 

The amendments and remarks presented herein are in response to the Office 
Action dated September 5, 2007. 

The Examiner objected to claim 29 as being a substantial duplicate of claim 28. 
Claim 28 has been cancelled. 

The Examiner rejected claims 3, 11, 13, 16, 29, and 21-29 under 35 USC 112 as 
allegedly being indefinite for failing to particularly point out and distinctly claim the 
subject matter of the invention. 

Claims 21, 22, 25, 26, and 29 have been amended to provide sufficient antece- 
dent basis for all limitations therein. Claim 28 has been cancelled. 
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The stated that in claims 3, 11, 13, 16, 19, 23, 24, and 27, the term "do not re- 
peat indicator" is allegedly vague and unclear. Claims 3, 11, 16, 19, and 23 have been 
amended to more particularly recite "an indicator that step d.3) [or c)] has been per- 
formed." Claim 27 has similarly been amended to recite "an indicator that a first re- 
quest has been received." This indicator, as defined in the specification, is a mecha- 
nism by which the system and method of the present invention determines that an 
initial request has already been serviced. Responsive to a request that includes this 
indicator, the claimed invention performs different steps, in some situations, that it 
does in the absence of this indicator, as clearly recited in the claims. 

Applicants respectfully submit that the claims now particularly point out and 
distinctly claim the subject matter of the invention, and that the 112 rejection has 
been overcome. Claims 13 and 24 have been cancelled. 

The Examiner rejected claims 1-20 under 35 USC 102 as being anticipated by 
Barnett. This rejection is respectfully traversed. 

Claim 1, as amended, recites: 

"A method for determining whether a client accepts visitor identifiers, comprising the 

steps of: 

a. ) receiving a request for a resource, the request originating at a client; 

b. ) determining whether the request for the resource includes a visitor identi- 

fier; 

c. ) responsive to the request not including the visitor identifier: 

assigning a new visitor identifier; 
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sending a redirection request with the new visitor identifier to the cli- 
ent; 

responsive to the client storing the new visitor identifier, determining 
that the client accepts visitor identifiers; and 

responsive to the client not storing the new visitor identifier, deter- 
mining that the client does not accept visitor identifiers." 

The claimed method determines whether a client accepts visitor identifiers. A 
request for a resource is received, for example at a server. The request originates at a 
client. A determination is made as to whether the request includes a visitor identi- 
fier. An example of such a visitor identifier is a cookie, although other types of visi- 
tor identifiers can be used. If the request does not include a visitor identifier, a new 
visitor identifier is assigned and a redirection request is sent to the client along with 
the new visitor identifier. Then, if the client stores the new visitor identifier, a de- 
termination is made that the client accepts visitor identifiers. If the client does not 
store the new visitor identifier, a determination is made that the client does not ac- 
cept visitor identifiers. 

Barnett fails to teach or suggest the recited limitations. Barnett merely de- 
scribes a method and system for generating and displaying a calendar containing 
user-selected events from user-selected categories. At col. 16, lines 56-65, Barnett de- 
scribes checking for an existing long-term session. If none exists, one is created. Fig. 
17 shows determining whether an auto-login cookie is found 1710; if not, the method 
redirects 1712 to a login screen and prompts 1713 for login. There is no mechanism 
in Barnett for making a determination as to whether a client has stored a new visitor 
identifier, nor of determining that the client accepts (or does not accept) visitor iden- 
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tifiers based on whether a new visitor identifier is stored, as claimed herein. In fact, 
the cited portion of Barnett merely describes the common and well-known mecha- 
nism of using information from a cookie if available, and prompting for a login if no 
cookie is found. The system described in Barnett would have no way of knowing 
whether or not the client is accepting visitor identifiers. By contrast, the present in- 
vention makes a definitive determination as to whether the client accepts visitor 
identifiers (such as cookies); an advantageous result of the claimed invention is that 
an alternative mechanism for storing state can be used when it is determined that the 
client is not reliably accepting visitor identifiers. 

The claimed method thus solves a problem that is entirely different from the 
scheme described in Barnett, which would not be able to determine whether or not 
the client accepts visitor identifiers. In fact, in a situation where the client is not ac- 
cepting visitor identifiers, the method described in Fig. 17 of Barnett would repeat- 
edly redirect to a login screen at each instance, failing to recognize that the client is 
not accepting cookies. Thus, Barnett would unnecessarily query the user repeatedly 
for login information instead of using an alternative mechanism for storing state. 
Barnett, therefore, does not offer any functionality for solving the problem addressed 
by the claimed invention. 

Accordingly, claim 1 is respectfully submitted to be patentable over Barnett. 

Claim 3, as amended, recites: 
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"A method for determining whether a requestor accepts visitor identifiers, comprising 
the steps of: 

a. ) receiving a request for a resource from a requestor, the requestor having 

an address; 

b. ) determining whether the request includes a visitor identifier; 

c. ) responsive to the request including a visitor identifier, obtaining data asso- 

ciated with the visitor identifier and determining that the requestor 
accepts visitor identifiers: 

d. ) responsive to the request not including a visitor identifier: 

d.l) determining whether the request includes an indicator that step 

d.3) has been performed; 
d.2) responsive to the request including the indicator that step d.3) 

has been performed, assigning a visitor identifier from the 

requestor's address and determining that the requestor does 

not accept visitor identifiers; 
d.3) responsive to the request not including the indicator that step 

d.3) has been performed: 

assigning a new visitor identifier; 

sending to the requestor a redirection request including the 
new visitor identifier and an indicator that step d.3) 
has been performed; and 

repeating steps a-d." 



The claimed method determines whether a client accepts visitor identifiers. A 
request for a resource is received, for example at a server. The request originates at a 
requestor. A determination is made as to whether the request includes a visitor iden- 
tifier. An example of such a visitor identifier is a cookie, although other types of visi- 
tor identifiers can be used. If the request includes a visitor identifier, the server ob- 
tains data associated with the visitor identifier and determines that the requestor is 
accepting visitor identifiers. If the request does not include a visitor identifier, the 
following steps are performed. First, the server determines whether the step d.3) has 
already been completed; in this manner, an endless loop is avoided. If step d.3) has 
previously been performed, a visitor identifier is assigned based on the requestor's 
address, since the requestor is not accepting visitor identifiers. This visitor identifier 
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based on the requestor's address is an alternative way to maintain state when the re- 
questor is not accepting visitor identifiers. If, on the other hand, step d.3) has not 
been completed, a new visitor identifier is assigned, a redirection request is sent 
(along with an indicator that step d.3) has been completed), and the process is re- 
peated. In this manner, a determination can be made as to whether the requestor is 
accepting visitor identifiers. 

Barnett fails to teach or suggest the recited limitations. As described above, 
Barnett merely describes a method and system for generating and displaying a cal- 
endar containing user-selected events from user-selected categories. At col. 16, lines 
56-65, Barnett describes checking for an existing long-term session. If none exists, 
one is created. Fig. 17 shows determining whether an auto-login cookie is found 
1710; if not, the method redirects 1712 to a login screen and prompts 1713 for login. 
There is no mechanism in Barnett for making a determination as to whether a re- 
questor has stored a new visitor identifier, nor of determining that the requestor ac- 
cepts (or does not accept) visitor identifiers based on whether a new visitor identifier 
is stored, as claimed herein. Furthermore, there is no mention anywhere in Barnett of 
a technique by which the server sends an indicator that a request response has previ- 
ously been completed so as to avoid an endless loop as claimed herein. 

As discussed above, the claimed method thus solves a problem that is entirely 
different from the scheme described in Barnett, which would not be able to deter- 
mine whether or not the client accepts visitor identifiers and would not be able to 
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avoid repeatedly attempting to use cookies as visitor identifiers. Barnett offers no 
solution equivalent or analogous to the recited mechanism for including an indicator 
that a request has previously been received and serviced so as to make a conclusive 
determination that the requestor does not accept visitor identifiers as recited herein. 
In fact, in a situation where the client is not accepting visitor identifiers, the method 
described in Fig. 17 of Barnett would repeatedly redirect to a login screen at each in- 
stance, failing to recognize that the client is not accepting cookies. Barnett, therefore, 
does not offer any functionality for solving the problem addressed by the claimed 
invention. 

Accordingly, claim 3 is respectfully submitted to be patentable over Barnett. 

Claim 11 recites a data collection server and includes limitations similar to 
those discussed in connection with claim 3. Claim 14 recites a client-based method 
including limitations similar to those discussed in connection with claim 1. Claim 16 
recites a client-based method including limitations similar to those discussed in con- 
nection with claim 3. Claim 18 recites a computer program product including limita- 
tions similar to those discussed in connection with claim 1. Claim 19 recites a com- 
puter program product including limitations similar to those discussed in connection 
with claim 3. Claims 2, 4-10, 12, 15, 17, 20-23, 25-27, and 29, as well as new claim 30, 
variously depend from claims 1, 3, 11, 14, 16, and 19 and incorporate the limitations 
discussed above. Accordingly, claims 1-12, 14-23, 25-27, 29, and 30 are hereby sub- 
mitted to be patentable over Barnett. Claims 13, 24, and 28 have been cancelled. 
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Claim 30 has been added in order to more particularly define the invention. 

Support for the claim amendments and the new claim can be found in the 
originally filed specification at, for example, paragraphs [0009], [0013], [0014], [0044] 
to [0046], and Fig. 2. No new matter has been added. 



On the basis of the above amendments, consideration of this application and 
the early allowance of all claims herein are requested. 

Should the Examiner wish to discuss the above amendments and remarks, or 
if the Examiner believes that for any reason direct contact with Applicant's represen- 
tative would help to advance the prosecution of this case to finality, the Examiner is 
invited to telephone the undersigned at the number given below. 

Respectfully submitted, 
Brett Error, et al. 



Dated: February 5, 2008 By: / Amir H. Raubvogel/ 

Amir H. Raubvogel 
Reg. No. 37,070 
Raubvogel Law Office 
820 Lakeview Way 
Redwood City, CA 94062 
Phone: (650)209-4884 
Fax: (650)362-1800 
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